home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Oct 89 / Z0132-Re NeXT…-Oct89 < prev    next >
Encoding:
Text File  |  1989-10-20  |  5.0 KB  |  106 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  BURBECK.S    to EYES
  2.  
  3. Item    3714398                         19-Oct-89        09:26
  4.  
  5. From:   PASCOE1                         Pascoe, Geoff
  6.  
  7. To:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    Re: NeXT…
  10.  
  11. NOTE: THE FOLLOWING REPRESENTS MY OWN OPINIONS AND NOT THAT OF APPLE
  12.  
  13. Alan,
  14.  
  15. The differences you see, for example, between Objective-C and Object Pascal is
  16. the direct result of three things:
  17.  
  18. 1) Run-time representation of meta-data,
  19.  
  20. 2) Run-time facilities for accessing and using that meta-data, and
  21.  
  22. 3) The differences between strict and lenient (or no) type checking.
  23.  
  24. To simplify matters, somewhat, one can view languages as a spectrum from those
  25. with little run-time support to those with a lot of run-time support.  I
  26. illustrate as follows-
  27.  
  28.        Lots of runtime       Smalltalk, LISP (comes in different O-O flavors)
  29.              |                    |
  30.              |               Objective-C
  31.              |                    |
  32.              |               Object Pascal
  33.              |                    |
  34.         Very little runtime      C++
  35.  
  36. Smalltalk and LISP provides lots of run-time support.  Flexible and dynamic
  37. messaging, explicit representation of messages, meta-data, etc.  For the most
  38. part, though, forget about static type checking (you might get some of this in
  39. some O-O versions of LISP- I'm not familiar with the newer O-O extensions to
  40. this language).
  41.  
  42. Objective-C also has a reasonable amount of run-time support.  It has a
  43. concrete representation of messages, some meta-data (not complete), but no GC.
  44. In the latest version of Objective-C (version 4.0) you also get optional
  45. typing.
  46.  
  47. Object Pascal has very little meta-data.  It does store an explicit structure
  48. for classes which has the class name and size of instances and retains some
  49. flexibility in it's messaging mechanism, although selectors don't have a useful
  50. concrete represenation.  The type checking is pretty strict here.
  51.  
  52. C++ tries to get rid of as much data as possible after compilation.  Meta-data
  53. is NIL and messaging uses the less flexible, but slightly more efficient
  54. V-table approach- so forget about selectors, they don't exist.  Type checking
  55. is strict, but you get lots of compile-time facilities like overloading.
  56.  
  57. What is it about the 3 things above that make doing an interface-builder type
  58. of thing easier?
  59.  
  60. First, you point out that since selectors have a concrete representation you
  61. can use a 'perform:' message to be very dynamic in sending messages.  This is
  62. especially useful when dealing with user-interfaces.  The more static languages
  63. will have to simulate this.  Of course, you pay penalties:
  64.  
  65.     1) Some storage overhead for selector representation,
  66.  
  67.     2) Potentially lots of overhead for code, since you can't tell until
  68.        run-time what message will be sent, you can't statically strip out
  69.        methods that won't be used,
  70.  
  71.     3) You give up type checking when you use 'perform:' (assuming you would
  72.        normally have it).  So, you can get run-time messaging errors.
  73.  
  74. Second, the existence of meta-data allows you to 'store-out' the representation
  75. of an object automagically to file and read it back in later.  If you have all
  76. objects (Smalltalk), you can use a recursive technique to tell all the objects
  77. to store themselves out.  If you have a hybrid environment (Objective-C), those
  78. instance variables that aren't objects have type-information in the class, so
  79. you know just what to do.  (Except in the world of C, where programmers don't
  80. expect things like structures or arrays to have meta-data, following anonymous
  81. pointers is definitely a problem.  Theoretically, the full typing of lots of
  82. agregate types can be stored for instance variable in the class, including the
  83. types of pointers in fields of structures, etc.  But currently, Objective-C
  84. doesn't deal with this well.  So, you have to do some extra work and/or be very
  85. careful.)  More static languages make the programmer reponsible for this kind
  86. of stuff (see, for example, TDocument.DoRead and TDocument.DoWrite).  Also,
  87. classes as objects clearly helps here too.
  88.  
  89. Third, lots of other things become easier, like inspectors and debuggers.  If
  90. the meta-data is ALL there then you don't need a 'Fields' method hand-coded by
  91. the programmer.  Interestingly, though, Objective-C's meta-data isn't complete.
  92. Classes have the types of instance variables but not their names, and selectors
  93. have their names available but not their types.  Clearly a very significant
  94. oversight.  If you're going to bite of the storage and performance penalty for
  95. doing this run-time stuff, you might as well make it complete.
  96.  
  97. Incidentally, there is no reason why Object Pascal or C++ could not support
  98. meta-data and lots of other stuff, although consistently strict type-checking
  99. can get in the way.  The semantics would change slightly, but most current
  100. programs (e.g., those that don't follow pointers and play bit-twiddling games
  101. with class structures) wouldn't be severely impacted.  I believe that ET++
  102. already does some of this for C++.
  103.  
  104. Geoff
  105.  
  106.